這句話在這個系列裡已經反覆出現過，今天想把它講得更完整。Day 4 講過「過度設計不是 AI 帶來的新病」，引用了 GOOS（Growing Object-Oriented Software, Guided by Tests）跟 ATDD 十幾年前就在處理同一個問題。今天想把格局再拉高一層：不只是過度設計,幾乎所有這個系列討論過的病徵——名不符實的抽象、規則失去意圖脈絡、機制腐化成化石——全都是軟體工程史上一直存在的老毛病,AI 沒有發明任何一種,它只是讓每一種毛病的發作速度都被放大了。
過度設計，早在物件導向設計流行的年代就有名字了——1998 年《AntiPatterns》一書歸類的「Golden Hammer」反模式，還有 Martin Fowler 在《Refactoring》裡點名的「Speculative Generality」（投機性泛化）壞味道，跟 ai-news-test 過度設計版本裡那 92% 從未被呼叫過的死碼,是同一件事的不同時代版本。「測試通過不等於設計正確」這個落差，本質上是 Kent Beck 講 TDD 時反覆強調的「先讓測試綠燈,再重構到乾淨」這個循環裡「重構」那一步被省略的結果——過度設計版本不是沒有測試,是有測試但沒有人回頭重構掉多餘的抽象。「規則失去意圖脈絡就變成化石」（Day 27 討論的規則腐化），對應的是任何團隊裡都可能發生的「Cargo Cult」現象——照抄一個曾經有道理的做法，卻忘了它原本要解決什麼問題。
這些病名都不是這幾年才發明的，它們比 AI coding agent 的歷史長得多。 這個系列真正在講的,不是「AI 帶來了一種新型態的壞程式碼」，而是「AI 把人類寫壞程式碼的速度，從『一個工程師一天寫幾百行』提升到『一個 prompt 幾秒鐘寫幾千行』」。
回到 ai-news-test 這個案例：745 個檔案、21,727 行的過度設計版本，如果讓一個人類工程師手動打字寫出來，需要的時間是以天甚至週計；但透過 AI coding agent，這個規模的程式碼可以在遠遠更短的時間內生成完畢。病灶本身沒有變新，變的是「從一句模糊需求，到一個 92% 死碼的系統」這段距離所需要的時間被壓縮了。 這正是 Day 1 講的「人的閱讀速度沒有變，AI 的產出速度變了」這個落差，在技術史的維度上的另一種講法：不是 review 方法論突然過時了，是舊方法論原本仰賴的「產出速度有限，人眼追得上」這個隱藏假設,被打破了。
這也是為什麼這個系列選擇回頭談 Outside-In TDD／ATDD 這套十幾年前的紀律，而不是發明一套全新的「AI 時代 review 方法論」。舊毛病用舊藥方是對的方向，只是這帖藥方現在比任何時候都更急迫地需要被吃，因為毛病發作的速度變快了。 如果因為病灶是舊的，就以為隨便應付一下也行,那才是真正低估了 AI 帶來的改變。
如果把這個時代命題誤讀成「AI 帶來全新問題」，容易導向一種解法：發明全新的、專門對付 AI 生成程式碼的工具跟規則，好像過去的軟體工程知識都不管用了。這個系列想傳達的立場正好相反：過去累積的軟體工程紀律（TDD、重構、架構邊界）不但沒有過時，它們現在比任何時候都更值得被認真執行，因為過去可以靠人手速有限而僥倖迴避的紀律缺口，現在會被 AI 的產出速度立刻放大成看得見的災難。選對敘事,才會把力氣放在「怎麼讓舊紀律被貫徹得更徹底」，而不是浪費在發明本質上不必要的新輪子。
回到系列主題句：AI 沒有發明過度設計，它只是讓過度設計的速度追上了你按下 Enter 的速度；Review 要跟得上，審的就不能再是程式碼本身，而是產生程式碼的規則。 今天這篇是把這句話從「過度設計」這一個具體病徵，擴大成一個對整個軟體工程史的命題：AI 加速的從來不是「寫程式」這個動作，是每一種本來就存在、只是發作得比較慢的舊毛病。
你們團隊最近一次因為 AI 生成程式碼而踩到的坑，如果拿掉「AI」這個關鍵字重新描述一次，是不是也可以套用在十年前某個資淺工程師寫出來的壞程式碼上？如果可以，代表你面對的可能不是新問題，是舊問題的新速度。
Day 29 要誠實列出這套方法論的邊界——有哪些情境，這個系列講的紀律反而不適用，甚至會拖慢速度。
十幾年前開始接觸測試驅動開發跟重構的時候，這些概念在當時的團隊裡也曾經被當成「額外負擔」而不被重視。現在看到同樣的抵抗心態換了一個對象——「AI 都幫我生成了,幹嘛還要照這些老規矩」——出現在完全不同的時代背景下，某種程度上讓我確定,這從來不是工具的問題，是紀律被認真執行與否的問題,工具只是把不認真的代價,兌現得更快而已。
iThome鐵人賽
看影片追技術